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Addendum to RFC 1602 -- Variance Procedure 


Status of this Memo 


This document specifies an Internet Best Current Practices for the 
Internet Community, and requests discussion and suggestions for 
improvements. Distribution of this memo is unlimited. 


Abstract 


This document describes a modification to the IETF procedures to 
allow an escape from a situation where the existing procedures are 
not working or do not seem to apply. This is a modification to the 
procedures of RFC 1602 and 1603. 


Introduction 


The current IETF procedures are documented in "The Internet Standards 
Process -- Revision 2" [1], and "IETF Working Group Guidelines and 
Procedures" [2]. 


There may be situations where following the procedures leads to a 
deadlock, or there may be situations where the procedures provide no 
guidance. In these cases it may be appropriate to invoke the 
variance procedure described below. 


A revision of the rules specified in RFC 1602 is underway, but may 
take some time. This document describes an interim amendment to RFC 
1602, to avoid having to wait for this major revision in a state of 
paralysis. 


Guiding Principles 


Any variance from following the written rules must be a public 
process with opportunity for all concerned parties to comment. 


The variance procedure should be similar to existing mechanisms and 
involve existing bodies. 
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The Variance Procedure 


Upon the recommendation of the responsible IETF Working Group (or, if 
no Working Group is constituted, upon the recommendation of the 
responsible ad hoc committee), the IESG may enter a particular 
specification into, or advance it within, the standards track even 
though some of the requirements of section 5 of RFC 1602 have not or 
will not be met. The IESG may approve such a variance, however, only 
if it first determines that the likely benefits to the Internet 
community from entering or advancing the specification on the 
standards track are likely to outweigh the costs to the Internet 
community that result from noncompliance with section 5. In 
exercising this discretion, the IESG shall consider (a) the technical 
merit of the specification, (b) the possibility of achieving the 
goals of the Internet standards process without granting a variance, 
(c) alternatives to the granting of a variance, (d) the collateral 
and precedential effects of granting a variance, and (e) the IESG’s 
ability to craft a variance that is as narrow as possible. In 
determining whether to approve a variance, the IESG has discretion to 
limit the scope of the variance to particular parts of section 5 and 
to impose such additional restrictions or limitations as it 
determines appropriate to protect the interests of the Internet 
community. 


There are five aspects that are involved in the variance procedure: 
(1) detecting the problem, (2) proposing a solution, (3) public 
review, (4) accepting the solution, and (5) an appeal process. 


1. Detecting the problem 


The responsible IETF Working Group, (or, if no Working Group is 
constituted, the responsible ad hoc committee), may bring the matter 
of a variance before the IESG. 


2. Proposing the solution 
The IESG is responsible for proposing the solution. 


The IESG may enter a particular specification into, or advance it 
within, the standards track even though some of the requirements of 
section 5 of RFC 1602 have not or will not be met. 


In exercising this discretion, the IESG shall consider (a) the 
technical merit of the specification, (b) the possibility of 
achieving the goals of the Internet standards process without 
granting a variance, (c) alternatives to the granting of a variance, 
(d) the collateral and precedential effects of granting a variance, 
and (e) the IESG’s ability to craft a variance that is as narrow as 
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possible. 


The IESG should consult WG chair and appropriate WG members as 
needed, and the wishes of the WG should also be taken into account. 


3. Public review 
There shall be an extended Last Call for public review. 
4. Accepting the solution 


The IESG is responsible for accepting the solution, and incorporating 
comments from the Last Call. 


The IESG may approve such a variance, however, only if it first 
determines that the likely benefits to the Internet community from 
entering or advancing the specification on the standards track are 
likely to outweigh the costs to the Internet community that result 
from noncompliance with section 5 of RFC 1602. 


In determining whether to approve a variance, the IESG has discretion 
to limit the scope of the variance to particular parts of section 5 
of RFC 1602 and to impose such additional restrictions or limitations 
as it determines appropriate to protect the interests of the Internet 
community. 


5. The appeal procedure 
The IAB is responsible for hearing and deciding appeals. 

Discussion 
When the IESG (on reviewing a recommendation for a variance) the has 
determined that there is a situation where the existing written rules 
do not apply or lead to a deadlock, the IESG may propose a solution 
to the problem. 


The solution may be developed by the IESG or suggested to the IESG. 


The solution may either (1) decide the particular instance of the 
matter, or (2) define a procedure for resolving matters of this kind. 


In any case, the proposed solution will be documented in an Internet 
Draft and subjected to an extended Last Call. 


Depending on the results of the Last Call, the IESG will either 


accept the solution; or revise the proposal, update the Internet 
Draft, and initiate another extended Last Call. 
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When the IESG accepts a solution the Internet Draft shall be 
forwarded to the RFC Editor and published as an RFC. 


The IAB shall be available to hear and decide on appeals of the use 
this variance procedure. 
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